LISTSERV was created before the World Wide Web was in general use. Back then, the primary way for most people to communicate with the LISTSERV program was by email, and this method is still widely used today. LISTSERV also includes a Web Interface to make communication easier and more intuitive. The Web interface is richly populated with on-screen information, tutorials, and wizards to help you use the program quickly and effectively.
When you want to perform actions using LISTSERV, such as adding a subscriber to a list, the action is based on a command LISTSERV receives by email or using the Web interface. Some commands are only available to LISTSERV maintainers and list owners, while other commands are available to subscribers and non-subscribers as well.
Sending email messages to LISTSERV containing commands and posting messages to the list is sometimes confusing for people new to mailing lists. To simplify this process, the Web interface provides a centralized location for interaction with LISTSERV. As a list owner, you can use the Web interface to issue commands directly to LISTSERV. You can also use the Web interface to post messages to the list. For details on using the Web Interface to create and maintain your lists, see the following sections:
There are two main email addresses that are used to work with LISTSERV lists. One is to communicate with the LISTSERV program — a “command address”, and one is used to post mail to the list — the “list address”. Any time the list configuration is changed or a subscription setting is changed, communication takes place with the LISTSERV program using the command address. Whenever a message is posted to the list, it is sent to the list address.
The command address will usually start with “LISTSERV@” and will be followed by the server name where the LISTSERV program has been installed. Messages sent to the command address should contain only commands to LISTSERV, one command per line. Lines containing non-commands will result in an error message being returned.
Tip: If sending commands from an email client that uses a “signature file”, make sure that the first line of the signature file is a line containing only “--” (two consecutive hyphens and a space) starting at the very start of the line. Otherwise, LISTSERV will attempt to interpret the signature text as commands and return “Invalid command” errors. This is the standard for the first line of a signature.
Email Command: You can also get a listing of commands by sending an email message to your LISTSERV server with the following command:
INFO REFCARD
A LISTSERV list consists of the list’s configuration (header) and any number of subscriptions. Each subscription includes an email address, a name, and the subscription “settings” or “options”. The list’s configuration regulates list behavior that applies to the entire list, whereas subscription settings regulate behavior that may be different for each subscriber.
A list’s configuration is defined by a set of “keywords” arranged in a format called a “List Header.” The keywords contained in the list header have values associated with them. The values of the keywords determine the behavior of the list. For example, a list header that contains the keyword “Attachments” with the value set to “No” will not allow any messages that include attachments to be sent to the list. Keywords can be added, removed, or have their values changed in a list header by sending a command to LISTSERV to replace the header.
Keywords and their associated values set the behavior of the list. This behavior in turn sets the “style” of the list. For example, the keyword “Send” and its associated value determine who is allowed to post messages to the list. A list that has the keyword “Send” set to “Owner” allows only the owner of the list to post messages to the subscribers. This creates a one-way communication style for the list – the owner can send messages to the subscribers, but the subscribers cannot send messages to the list for distribution.
A list of this type might be used for newsletters or product announcements. A list with the keyword “Send” set to “Private” would allow the list owner and the subscribers to that list to send messages to the list, setting up a two-way communication style list. This type of list could be used for collaboration or discussion among the subscribers. See Section 4
Mailing List Types for descriptions of the three most common types of mailing lists.
There are more than 50 keywords that can set the behavior of mailing lists. Keywords can be added, removed, or have their values changed by using the Web interface or by sending an email message to the LISTSERV program using the command address.
For the sake of security, there are a number of actions for which LISTSERV requires confirmation before proceeding. In some cases, LISTSERV will accept a password-based validation. In other cases, email confirmation is required. When this happens, LISTSERV sends an email message with a subject line such as:
Subject: Command confirmation request (787EF897)
The string of “hexadecimal” numbers in parentheses (“787EF897” in the example) is called a “cookie” (sometimes referred to as a “confirmation code”) and is different every time. The text of the message will look something like this:
In the figure above, the owner sent an email command to delete all subscribers from a list that is configured such that it requires list-owner commands to be validated (
Validate=Yes,Confirm). As the “delete” command did not include the owner’s password, LISTSERV sent an email requesting confirmation of the command.
When you receive a command confirmation request, you must confirm within 48 hours (this time may be configured differently using the Confirm-Delay= keyword) in order for the command to be executed. There are two ways of confirming the command, using the Web interface or using email.
Tip: If this method is not successful, then you can send a new message to the LISTSERV command address using the “
OK xxxxxxxx” command, where “
xxxxxxxx” is the cookie copied from the original confirmation request.
The cookie is the key to the “OK” confirmation method of validation. LISTSERV randomly generates a new cookie for each action that requires validation. Only someone with access to the email address to which LISTSERV sends the cookie knows what the cookie is. All of the privileges within LISTSERV are tied to an email address, so when LISTSERV needs to verify that a command was really initiated by the owner of a particular email address, it uses the “
OK” confirmation method.
Caution: Never “
OK” a cookie blindly. Make sure that it is for a command that you initiated or for a message that you want to have distributed to the list. Several cases of list “hijackings” or spam sent to well-secured lists have been traced back to a list owner or moderator absent-mindedly clicking an OK link that they should not have clicked.
|
•
|
Postings to a list with Send=…,Confirm (sender must confirm that the message came from them – strongly recommended for one-way lists, such as newsletters).
|
|
•
|
Subscription requests for a list with Subscription=Open,Confirm or Subscription=By_Owner,Confirm. Subscription confirmations are strongly recommended on public lists, to prevent unwanted third-party subscriptions.
|
|
•
|
DELETE or ADD commands sent over email without a password, on a list with Validate=Yes,Confirm.
|
As these examples illustrate, the list configuration controls most of the conditions under which confirmations are required. The list owner must decide on the right balance between security and convenience for the list. For more information, see the
List Keyword Reference document.
